Currently an increasing number of video streaming techniques make use of so-called segmentation. For example, in HTTP adaptive streaming (HAS), Scalable Video Coding (VCS) and spatially segmented content (e.g. tiled video) use segmentation on the basis of time, quality and space respectively. During the segmentation process a so-called manifest file will be generated which describes the relation between the different segments and the location where the segments may be retrieved.
Segmented video content may be used to dynamically adjust the bandwidth requirements, e.g. by switching from a high to a low quality video stream. Moreover, segmented video may also allow division between popular and less popular video segments. For example, typically content associated with the beginning of a video will be watched more often (more popular) than content at the end. Similarly, low-bitrate lower-quality video content (e.g. the lowest resolution HAS segments or the SVC base layer) will be watched more frequently than high quality content (e.g. higher-resolution HAS segments or an SVC enhancement layer). Hence, when segmenting video content, certain segments will be (much) more often requested by consumers than other segments. This property may be advantageously used by a content delivery network (CDN) which is configured to deliver content to a consumer. It may for example store the segments associated with more popular content at multiple nodes in the CDN so that the bandwidth problem may be reduced and efficient delivery is guaranteed. A CDN content location manager may centrally manage the locations within the CDN where the segments may be retrieved.
In some cases the segments associated with one piece of content may be stored at nodes which belong to two or more different CDN domains. In that case, no central location manager is available to locate the segments in the different CDN domains. Therefore, a manifest file associated with a first CDN may only refer to a routing function in the further CDNs as the first CDN has no knowledge about the location of the segments in the second CDN. Hence, every time a segment in another CDN is requested, a routing request to that CDN is required. Such requests may generate request-routing delays so that its takes a longer time in order to receive the requested segment.
Such routing requests may have negative effects on the performance of the CDN. Content comprising a large number of segments may require a large number of routing requests to other CDNs thereby drastically increasing the request routing load per user. Moreover, routing-request delays may also negatively influence the performance of the client, especially when the client allows user-interaction with the content (e.g. zooming and panning request in case of spatially segmented content). The routing request delays may cause delays in displaying certain requested content thereby negatively influencing the user experience.
CDN interconnect schemes other than the above mentioned routing request mechanism are described in http://tools.ietf.org/html/draft-peterson-cdni-strawman-00. In this article a scheme is proposed on the basis of DNS look-ups and HTTP redirects. Such techniques however require multiple redirects per requested segment thereby introducing undesirable delays, which are undesirable when using content services which require short response times for fast content interaction.
Hence, there is a need in the prior art for efficient localization of segments distributed over two or more CDN domains. In particular, there is a need for methods and systems for localization of segments in multiple CDN domains such that segments may be delivered to a client with minimal delay thereby enabling content services for content play-out devices which require user-interaction functionality e.g. panning, zooming, tilting, seamless switching between high- and low resolution version, etc.